基于 VMware vSphere 的超融合平台怎么选？
目录
为何要建设基于 vSphere 的超融合平台
超融合架构核心是解决存储问题
由 SAN 存储引起，且亟待解决的问题
vSAN 与 SmartX 两种不同的解决思路
部署架构对比
性能加速
运维简化
小结 - 附《VMware 国产化替代专题》电子书
为何要建设基于 vSphere 的超融合平台
近年，超融合架构逐渐成为企业青睐的新型 IT 基础架构，它突破了旧有架构的局限性，有更强的扩展能力以及更好的易用性，但真正面临超融合选型时，众多技术选项却为企业带来一定的困扰。
众所周知，超融合软件主要由服务器虚拟化软件和分布式存储软件构成，服务虚拟化平台是可选的，那么是使用厂商默认提供的虚拟化软件（一般基于 KVM 虚拟化），还是采用更为熟悉的 VMware vSphere 或者 Microsoft Hyper-V 等商业虚拟化平台？也许这个问题对于从来没有使用过服务器虚拟化软件的企业来说更简单，因为一切都是新的；但对于另外一部分已经在大规模使用服务器虚拟化技术的企业来说，就是另外一个故事，选择上不免有一些举棋不定。
据计世咨询在 2020 年的统计，VMware vSphere 在中国依然是虚拟化软件使用占比第一（比例正呈现逐年下降的趋势），达到 31.59%。
超融合架构核心是解决存储问题
由于 VMware vSphere 有庞大的用户基础，因此为数不少的用户在转型超融合架构时，依然会优先考虑 VMware vSphere 虚拟化，主要判断依据来自以下几点：
沿用 vSphere 平台，业务系统免除再次验证和优化的过程，并且相同平台间的迁移更加平滑。
基于 vSphere 的生态比较成熟，已有的投资（如相关的备份、安全、许可等投入）可以重复使用。
对 vSphere 的管理更加熟悉，管理员无需额外的学习成本。
对于已经大量使用 VMware vSphere 的用户，有以上顾虑也是很容易理解的。当用户在选择不改变虚拟化平台前提下去转型超融合架构，实际上是替代原有的集中式存储（主要是 SAN 存储）方案 。在这种情况下，方案上更注重解决在虚拟化环境下集中式存储面临的一些问题。当我们真正搞清楚存储问题在哪里，那么方案的轮廓也会自然变得清晰了。
由 SAN 存储引起，且亟待解决的问题
难以快速应对业务及资源需求变化
对于业务系统来说，很多时候计算资源和存储资源的需求增长并不同步。对于已上线的业务系统，在一段时间内计算资源的消耗通常是固定的（除非业务量短时间内爆发增长），但存储资源消耗的增长却是持续的（系统每一秒钟都在产生新的数据并要求存储下来）；而对于新业务增长，计算和存储资源的需求是同时发生的。这个因素也使得存储资源的需求变化来得更为剧烈。
而在传统架构中，计算资源和存储资源是独立管理的。服务器虚拟化使得计算资源的扩展变得简单，并且服务器的采购流程和上线流程一般都比较短（通常可以控制在 2-3 周左右），企业甚至可以库存少量服务器，应对突发的需求。
当存储资源不足的时候，由于 SAN 存储设备采购和部署的流程很长（通常需要 1-2 个月，甚至更长），并且库存也更为困难（配置难以标准化，成本更高）。最终导致的结果是：基础架构难以快速适配业务的资源需求变化。
加剧基础架构管理的复杂性
性能问题难以解决
随着服务器的 CPU 核数越来越多，虚拟机部署密度越来越大，并发访问存储的压力也随之增大；然而单台 SAN 存储的性能则受限于存储控制器（上限基本固定），即使存储容量在扩展，但存储性能并无法得到线性的扩展（反而呈现抛物线）。随着数据量增加，并发访问压力增大，最终导致存储的延时不断增大，系统响应不断变慢，业务部门频繁投诉；对于这一切，管理员似乎(除了申请另购新的存储设备之外)束手无策。
繁重的数据迁移工作
新增存储设备并不能轻易解决问题，多个存储设备的资源并没有实现池化，管理员需要不断地在不同的存储之间执行数据迁移以维持负载的平衡；在一些新老存储替换时，管理员甚至需要处理上百个存储卷的迁移，工作不但繁复，且容易误操作。
数据管理，运维压力大
RAID 组数据恢复窗口长这件事一直困扰着管理员，一块 TB 级别容量硬盘发生故障，恢复时间数小时到数天不等，数据恢复过程对存储性能影响较大，并伴随数据丢失风险，甚至恢复过程经常需要人工干预；因此，管理员经常承受较大的压力。
比较新的 SAN 存储控制器升级已经可以支持在线执行，但前提是多链路的设计得当，否则很容易出问题，对管理员的专业性要求比较高。
当你同时拥有多套 SAN 存储时，以上问题会迅速蔓延，管理复杂性大幅增加。当然有人会说传统存储更通用，但当你的业务越来越多运行在虚拟化环境中，那就更难找到非传统存储不可的理由。正是这些问题促进了超融合架构的诞生。下面我们将通过介绍和对比两种超融合产品的特性，分析它们是如何解决基于 vSphere 环境下的存储问题。
vSAN 与 SmartX 两种不同的解决思路
说到基于 vSphere 的超融合产品，很多人第一反应就是“师出同门”的 vSAN，甚至会认为 vSAN+vSphere 的组合是“最佳组合”，相信也有不少人好奇：事实是这样吗？我们可以看完文章再作结论。另外， SmartX 是国内少数可支持 vSphere 超融合部署的厂商，跟 vSAN 比起来有什么优劣？下面我们将针对两种方案进行多方位的对比。
部署架构对比
vSAN 与 vSphere 紧耦合集成
vSAN 软件是一款分布式对象存储软件，它集成在 ESXi 内核，管理主机上的所有磁盘，并将磁盘资源池化，为 vSphere 提供存储服务。vSAN 在 vSphere 的用户眼中更像是一个内置的功能的存在，只需开启就能用起来（实际上也需要符合硬件条件以及独立的授权许可）。同时 vSAN 在管理上非常依赖 vCenter ，包括集群创建、关闭、管理都必须通过 vCenter 来完成。vSAN 与 vSphere 属于紧耦合的集成关系。
vSAN 与 ESXi、vCenter 三者之间的关系非常紧密，实际部署时需要注意它们之间的版本的兼容关系，其中 vSAN 和 ESXi 关系最为紧密，从 6.5 版本之后，两者的版本基本是一一对应的，相对简单。
因此，vSAN 与 vCenter 的兼容性更为重要，从兼容矩阵可以看到， vCenter 的版本必须高于或等于 vSAN 版本，也意味着每一次 vSAN 版本升级必然要求 vCenter 同时升级。
SmartX ZBS 与 vSphere 松耦合集成
SmartX ZBS 分布式块存储软件（vSAN 属于对象存储），同样它提供将多个主机的硬盘资源池化的功能，并支持与多种虚拟化平台集成构建超融合方案。但 ZBS 与 vSphere 的集成部署方式比较特别，它实际上是一台运行在每台 ESXi 主机上的特殊的虚拟机（SCVM，全称 SmartX Controller Virtual Machine），并通过硬盘控制器透传的方式访问和管理磁盘。这种集成方式比较松散，SCVM 实际上与其他 ESXi 的普通虚拟机并没有太大差别。
在这种集成机制下，SmartX ZBS 与 vSphere 关系并没有这么（vSAN 内核集成）紧密，甚至两者的版本升级可完全独立进行，但部署过程要相对 vSAN 要复杂些。
性能加速
SAN 存储性能问题的几个诱因
混合配置（SSD+HDD）存储的缓存加速机制有诸多限制，导致性能提升效果非常有限。
全闪配置存储阵列大多时候无法充分发挥 SSD 的性能优势，难免出现“高薪低能”的情况。
受限于架构，控制器难以扩展，最终存储控制器容易成为存储的性能瓶颈。
无论 vSAN 还是 ZBS 大体上都是利用分布式存储的技术解决了传统存储的控制器性能瓶颈和提供一套控制器高效扩展的思路。只是两者在具体实现上有不同的机制。
vSAN 的磁盘组缓存机制
磁盘组缓存机制
vSAN 的存储性能加速机制主要通过 SSD 作为缓存加速 IO 读写。该机制是以磁盘组为单位，其中有且仅有 1 块 SSD 作为缓存盘用作加速 IO 性能，另外搭配 1-7 块磁盘作为容量盘。每个 vSAN 主机至少需要包含 1个磁盘组，最多支持 5 个磁盘组。
vSAN 将缓存盘容量分为两个区域，读缓存区域和写缓存区域，其中读缓存 70%，写缓存 30%（这个比例是固定的）；而全闪配置中，缓存盘依然是必需的，但只作为写缓存使用且最大容量为 600GB。
磁盘组的机制有两个明显的问题：
缓存盘是磁盘组独占，即无法共享也无法互相冗余，容易出现缓存利用率失衡。
缓存盘有且只有 1 块，一旦发生故障，该磁盘组整体失效，数据恢复量大。
数据副本分布机制
vSAN 数据副本分布机制是分散放置（一个虚拟机的数据分片可能分布在多台主机中），不提供数据本地化的功能。vSAN 认为虚拟机本身是会经常在线迁移的，因此数据本地化并没有必要，相反数据分散放置可以利用到多个节点的性能。
ZBS 全局缓存机制与数据本地化
全局缓存机制
ZBS 同样是采用 SSD 作为缓存加速 IO 读写，每个 ZBS 主机需要配置至少 2 块 SSD 作为全局缓存加速主机本地所有 HDD 性能，与 vSAN 不同的是，在全闪集群中不需要独立配置缓存盘，并且缓存容量不严格区分读缓存区域和写缓存区域，不设置固定的比例，更加灵活。
全局缓存加速的优势有几点：
缓存盘是主机内共享的，利用率更高。
当系统缓存空间不足时候，可添加 SSD 盘快速扩展缓存空间。（一个 vSAN 磁盘组只能有一个缓存盘，无法组内扩展）。
缓存盘支持互相冗余，即使遭遇一块缓存盘故障，不会引起大量的数据恢复，对系统影响比较小。
数据本地化放置机制
ZBS 考虑到数据本地读取路径最短、性能更好的因素，提供了数据本地化的功能，当虚拟机写入数据时，会优先在虚拟机本地写一份，远程主机写另外一份，这样做可以保证虚拟机读取数据时可以在本地完整读取数据，无需跨网络读取，有效降低延时。
同时 ZBS 考虑到虚拟机在主机之间迁移的情况，当虚拟机发生迁移后，系统将自动感知，并在 6 小时后自动触发数据迁移，在虚拟机新目标主机上重新形成完整副本，保证数据本地化的持续有效。
* 仅限于 ESXi 7.0 U2 以上，配合 ZBS 最新的 VAAI 插件实现。
运维简化
SAN 存储运维复杂
频繁数据迁移的根源是存储资源碎片化
以使用 vSphere 为例，存储需要划分固定大小的逻辑卷映射到 ESXi 主机，然后通过格式化为 datastore 使用。大规模虚拟化后会发现你的 vSphere 主机需要管理的 datastore 变得越来越多。这些 datastore 容量大小不同，性能不一致，甚至来自不同的存储设备。存储资源碎片化的根源是：
逻辑卷（lun）本身是难以在线扩容的，于是只有不断新增卷的数量。
有些情况需要考虑到存储性能问题，卷的容量也不得不划分得更小。
卷达到主机的最大容量限制，vSphere 支持最大单卷容量 62TB（老版本只有 2TB）。
数据恢复慢的核心问题是 RAID 技术过时
传统 RAID 组的数据恢复慢，是因为无论 RAID 组由多少块盘组成，数据恢复只能写入单块热备盘中，因此是完全受限于单块硬盘的性能。以一块 2TB 7.2K rpm 的硬盘为例，重构时平均写入速度只有 30M/s 左右，完成重构时间长达 18 个小时，因此重构过程中出现新的坏盘概率到大大增加，数据丢失的风险也大大增加。
升级工作难度大
传统存储控制器的升级大多都无法在线进行。倒不是说技术上无法支持，而是前置条件太多：需要前期多路径的规划得当，管理员需很清楚 SAN 网络的拓扑并掌握复杂的升级步骤，任意一个错误都能引起在线升级失败，对管理员专业性要求较高。
vSAN 采用网络 RAID 技术
vSAN 为了克服传统 RAID 限制，将硬盘切分更小的单位 – component，将跨主机的多个 component 通过网络组建 RAID 组，可增强磁盘并发访问能力，可理解为改进版的 RAID 技术（默认情况下 component 最大容量是 255GB）。它支持 RAID 1\5\6 三种 RAID 模式，默认存储策略采用 RAID1。
如下图，默认情况下虚拟机的数据文件都至少包含 2 个副本，组成 RAID 1 Mirror。数据文件副本分别放置在服务器 2、3 上，放置在不同的主机上，即使面对服务器宕机，依然可以访问剩下的一个副本；为了防止脑裂（网络故障产生）的情况，每组副本里面包含一个见证（witness）文件，它需放置在另外一台主机上（不能与前面 2 个数据副本放置在同一主机）。
当主机发生故障，系统通过冗余副本重建 RAID1，恢复数据保护级别。
但这种机制在只有 3 台主机组成的集群中有一些限制：由于 2 个数据副本和 1 个见证必需至少放置在 3 台不同的主机上，当某个主机发生故障，这种情况下（集群剩下 2 台主机）将无法完成 RAID1 重建，导致数据保护的级别降低，引发数据风险。
ZBS 采用分布式副本技术
SmartX ZBS 的虚拟机数据冗余机制采用元数据服务+副本的技术，它支持 1/2/3 副本策略。
这种冗余机制是将虚拟磁盘切分成为多个小的数据分片（256MB），以 2 副本策略为例，每个数据分片都包含 2 份副本，虚拟机本地一份，其他主机存放一份。元数据服务记录了数据分片各种信息，包括位置、状态等等。与 vSAN 的机制不同的是，这种机制无需见证对象，由元数据服务来防止脑裂的发生。
因此，SmartX ZBS 即使在 3 主机的小型集群中，某个主机遭遇故障，依然能正常触发数据恢复，保障数据的冗余级别。
vSAN 与 ZBS 的运维对比
欲深入了解 ZBS 功能与特性，请阅读：
小结
通过上文可以看出，vSAN 和 ZBS 通过不同思路提供基于 vSphere 的超融合解决方案，两者都有能力解决传统存储遗留的一些棘手的问题。vSAN 并不是基于 vSphere 超融合的唯一正解，ZBS 在此方案中有不少突出的亮点和优势，为大家在超融合选型中提供了另外一个选项。
更多 VMware 替代技术路线评估与用户实践案例，欢迎下载阅读电子书《VMware 国产化替代专题》！
您还可以关注 SmartX 用户社区，在 SmartX 学院中获取更多关于 IT 基础架构的干货内容与直播课程。
推荐阅读：